Encoding in HTML code Both NewsLetter and XMail (the mailer engine) fully support Unicode text (this means you can enter whatever thing in the HTML text field, and it will arrive ok to the target email client). But... (read further if you wanna support whatever encoding in your HTML docs, and apparently NL doesn't offer such feature). But... Emails are composed as follow (in NewsLetter, and it uses a standard method): Headers Part 1 Part 2 Part 3... Every part contains whatever data. For example, "Part 1" could contain "plain text" (though such concept doesn't really exist), and it is encapsulated using a "Encoding" (quoted printable) and a "Charset" (utf-8), which instructs the target email client to decode the text using the quoted-printable algorithm, then displaying the text using the utf-8 table. Now, when the thing is not simple text, but HTML, the email client must first un-quoted-printable the text (the html code), then display it according to the specified charset (utf-8). But, appart from this, the HTML should contain a HTML tag specifying its own charset (whatever is it), and the email client should render the HTML code according to this meta-tag. This means that HTML in emails should go thru 3 phases: decoding (eg, from quoted-printable), interpreting (read the decoded thing using a specified charset), HTML display (render as in a regular web browser, following the directives -if any- in the META tags). But... Most of email clients will plainly ignore META tags. So, if you send this: <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body> √° </body> </html> Most probably you will read in your email client "√°" (instead of "á"). The meta tag has been ignored. I've tested this in Apple's Mail, Microsoft Entourage and PC's Outlook. On the other hand, if you substitute "√°" with "á", it will display OK. Obviously, this is malformed HTML, but will work in such email clients. Actually, I don't know of a reliable workaround, as the explained thing doesn't depend on the "send" part, but on the "receive" one. The exposed code won't work fine when you receive it in Entourage (as for today), but will work when you read it from i.Scribe, or when the email client uses an external web browser to render the html code (for example, PowerMail did this in the past, I don't know now...). If you think there is something wrong in this explanation, please let me know. Anyway, we will be implementing support for different encodings very soon. |